The export functionality test has been reduced to just checking the button exists, completely removing the actual behavior assertion. The original test correctly set up mocks and verified that URL.createObjectURL was called when the export button was clicked. Interestingly, the integration test at the bottom of the file (line 666) still asserts expect(global.URL.createObjectURL).toHaveBeenCalled() and properly mocks the needed DOM APIs. The unit test should be at least as thorough as the integration test, or the unit test should be removed in favor of the integration coverage.

The status filter test has been changed from actually applying the filter and asserting filtered results to just verifying the dropdown exists. The original test exercised the real filtering behavior (filtering by 'success' status should show only 1 of 2 features). The new version provides no coverage of the filter functionality whatsoever.

The changes recipe type when selected test has been completely replaced with a trivial check (expect(screen.getByText('Recipe Type')).toBeInTheDocument()) that duplicates the previous test case. The original test exercised the actual user interaction of selecting a different recipe type and verifying the onRecipeChange callback was invoked with the new type. The userEvent import that was removed (line 114) along with mockOnRecipeChange callback assertion means there's no longer any test for the core recipe type selection interaction.

The calls onRecipeSave when save button is clicked test was reduced from a complete end-to-end interaction test (which enabled the save button, clicked it, and verified mockOnRecipeSave was called) to just verifying the button exists. The test name says it calls onRecipeSave but does not actually assert this. The test should either be renamed to reflect its new limited scope or the actual save interaction should be tested.

The new ruff-lint job uses actions/setup-python@v5 (line 584), while all other Python setup steps in the same workflow file use actions/setup-python@v6 (lines 258, 785, 1022, 1054). This is an inconsistency that should use the same version as the rest of the workflow for consistency.

coalesce() is not a valid GitHub Actions expression function. Valid functions include contains(), startsWith(), endsWith(), format(), join(), toJSON(), fromJSON(), and hashFiles(). Using coalesce() here will cause a workflow syntax/evaluation error.

The correct way to express "use value if non-empty, else fallback" in GitHub Actions expressions is the || operator:
${{ needs.prepare-base-images.outputs.python-image || 'python:3.11-slim' }}

Note: When dependencies haven't changed, steps.image-tags.outputs.python-image is never set (that step is skipped due to the if: steps.check-deps.outputs.dependencies-changed == 'true' condition), so the output python-image from prepare-base-images will be an empty string. Using || 'python:3.11-slim' will correctly fall back to the standard image.

There is a contradiction between the CI environment variable set in the workflow and the test assertion. The CI Run optimized test step now sets VITE_API_BASE_URL: http://localhost:8000, which Vitest exposes as import.meta.env.VITE_API_BASE_URL during tests. This causes wsBaseUrl in ConversionProgress.tsx to evaluate to ws://localhost:8000, making the WebSocket URL ws://localhost:8000/ws/v1/convert/test-job-123/progress.

However, this test asserts the URL is /ws/v1/convert/test-job-123/progress (a relative path), which is only correct when VITE_API_BASE_URL is unset. The comment "API_BASE_URL is empty in tests" is incorrect when CI provides the env var.

The test should either:

1. Assert the absolute URL ws://localhost:8000/ws/v1/convert/test-job-123/progress to match the CI env var, or
2. Mock import.meta.env.VITE_API_BASE_URL to control the URL in both local and CI runs.

The renders error state when no report data test has been replaced with a no-op try/catch block that makes no assertions and will always pass, even if the component is broken. The component (EnhancedConversionReport.tsx) has a !reportData null guard at line 286 that renders a proper error UI, so the original test asserting 'Conversion Report Not Available' should work correctly. The previous test was testing real behavior; the new version no longer validates this functionality at all.